Skip to content

Conversation

@lkdvos
Copy link
Member

@lkdvos lkdvos commented Jan 12, 2026

This was already changed for eigh, and I now made this consistent.

However, while playing around with this I have to say that I don't think we are sorting the LAPACK factorizations either, so this seems inconsistent with that now.
I then browsed through what LinearAlgebra does, and they very explicitly mention that for Diagonal inputs sortby might not be supported, and the sorting of the eigenvalues is not consistent between D and Matrix(D) + eps (note that the eps is necessary since LinearAlgebra does a runtime check for diagonal, therefore leading to the incredibly stupid difference between a diagonal eigendecomposition and a matrix epsilon away from that)

@Jutho
Copy link
Member

Jutho commented Jan 12, 2026

Indeed, I thought they were sorted, but it is Julia's LinearAlgebra that sorts them; the default LAPACK output is unsorted. Is that than not the reason why we only implemented this for eigh, where the LAPACK output is always sorted?

@lkdvos
Copy link
Member Author

lkdvos commented Jan 12, 2026

I don't really know, I'm fine with either since I don't think this is ever all that useful, but it's definitely not intuitive that we do explicitly sort some but not all cases.

In principle I can also try and come up with a more general interface for sorting as a post processing step which we then use everywhere, but the fact that the output type of the diagonal decompositions changes depending on whether or not we sort the values feels a bit off still.

@lkdvos
Copy link
Member Author

lkdvos commented Jan 15, 2026

So I slightly changed the implementation - the idea is that Diagonal eigenvalue decompositions should just work and more or less follow the output types of the regular ones.
Therefore, this no longer specializes the eigenvalues to remain real and also promotes them to complex.
I think the idea is that if you want the most performance, you probably will not be diagonalizing a diagonal matrix, so this is mostly about convenience. Therefore, we should prioritize not deviating too much from the regular array case.
This also simplifies some of the tests.
I will wait for the tests to finish and then update the changelog if everything works.

@lkdvos lkdvos enabled auto-merge (squash) January 15, 2026 10:41
@lkdvos lkdvos changed the title Sort diagonal eig values Sort diagonal eig values and standardize output types Jan 15, 2026
@lkdvos lkdvos requested review from Jutho and kshyatt January 15, 2026 10:41
function check_input(::typeof(eig_full!), A::AbstractMatrix, DV, ::DiagonalAlgorithm)
m, n = size(A)
@assert m == n && isdiag(A)
((m == n) && isdiag(A)) || throw(DimensionMismatch("diagonal input matrix expected"))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we print the actual dimensions here with a lazy string?

function check_input(::typeof(eig_vals!), A::AbstractMatrix, D, ::DiagonalAlgorithm)
m, n = size(A)
@assert m == n && isdiag(A)
((m == n) && isdiag(A)) || throw(DimensionMismatch("diagonal input matrix expected"))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above

@lkdvos lkdvos disabled auto-merge January 15, 2026 13:06
@lkdvos
Copy link
Member Author

lkdvos commented Jan 15, 2026

I will merge and address the comments in a follow-up!

@lkdvos lkdvos merged commit 8ec0063 into main Jan 15, 2026
8 of 9 checks passed
@lkdvos lkdvos deleted the ld-eig branch January 15, 2026 13:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants